Display List

Hi,

1) Du schreibst die Adresse Deiner DisplayList in die Hardware-Register für die Displaylist Meines Wissens ist es aber so, daß solange der Atari mit normalem OS läuft, die laufenden Routinen des OS die Adresse der DisplayList aus den Schattenregistern in die Hardwareregister schreiben, und zwar (bei PAL) 50x pro Sekunde. Das heißt, wenn Du was in die Hardwareregister schreibst hast Du maximal eine 50tel Sekunde Zeit, Dein Arbeitsergebnis zu betrachten. Du müßtest also die Werte in die zuständigen Schattenregister eintragen. (Die 50x pro Sekunde laufende Prozedur nennt sich Vertical Blank Interrupt und den gibt es in 2 Wichtigkeitsstufen, immediate und deferred).

2) Zum Unterschied zwischen ANTIC und GTIA Grob gesagt bearbeitet der eine die Grafik im Arbeitsspeicher und der andere macht daraus ein Videosignal. Das ist aber nur sehr grob betrachtet.

3) Die DisplayList gibt an, in welcher Form der Arbeitsspeicher auf dem Bildschirm darzustellen ist. Allerdings muß auch noch angegeben werden, wo die Daten stehen, die angezeigt werden sollen. Das geschieht mit einem LoadMemoryScan (LMS) Eintrag. Und am Ende der Displaylist muß ein Jump-Befehl hin der darauf zeigt, wo als nächstes mit der DisplayList weiter gearbeitet werden soll. Das ist in der Regel der Anfang der DisplayList.

Wenn Du nun eine einfache DL erzeugt hast (z.B. 3 Leerzeichen und eine GR0 Zeile mit LMS und Du hast zuvor was in die Speicheradressen reingeschrieben, auf die LMS zeigt dann sollte da auch was auf dem Bildschirm erscheinen - vorausgesetzt die DL Adresse steht dann auch in den Schattenregistern.

Hab ich übrigens gerade so ausprobiert (im Debugger). Hat funktioniert. Wenn man da jetzt Text in der GR0 Zeile sehen will muß man die Bytes im Speicher allerdings im Bildschirmcode ablegen. Für "ABCD" also die Bytefolge $21,$22,$23,$24.

CU, Erhard

Die Display List macht bei PAL und NTSC eher keine Probleme. Nutzt Du allerdings DLI oder VBI, kann das schon problematischer werden.

Allerdings gibt es gerade bei alten Fernsehern, das Problem, dass NTSC TV weniger darstellen können, als PAL TV. Daher hatte ATARI normalerweise immer 3 (8) komplette Leerzeilen in den Standard Grafikmodi verwendet ($70 bzw. 112) am Anfang jeder DL. Somit sollte jede Rechner/TV Kombination alles anzeigen können, was oben genauso gebaut ist und nach unten halt maximal 24 (8) Zeilen hoch ist.

Bis zu 30(*8) (also 240 einzelne Zeilen) ist am Atari möglich und moderne TV haben damit auch kein Problem.

... hallo yMoreT8,

ich hatte dir ja eine einfache Beispiel-DL gepostet. In deinem Beispiel hast du Fehler drin: Nimm nicht die Hardwareregister $D402/03 sondern besser die Schattenregister $230/31 lda #>dlist holt den High-Byte-Wert von dlist und schreibt mit sta dlstl in den Low-Byte-Wert des Registers ein und umgekehrt. Das kann ja nicht funktionieren.

Die Displaylist ist übrigens zunächst etwas kompliziert erscheinend, birgt aber echt coole Möglichkeiten, wo unser kleiner Atari anderen Rechnern deutlich überlegen war. Die Displaylist ist quasi eine kleine Programmroutine, die der Antic abarbeitet. Dem Antic muss ich natürlich sagen, wo diese Routine im Speicher steht, das mache ich mit den Anweisungen lda #dlist / sta dlsth Nun weiß der Antiv, wo diese Routine steht und arbeitet die Befehle ab: Die drei 112 Anweisungen braucht es nicht zwingend. Hier wird der schwarze Balken am oberen Rand erzeugt, was füher bei den Röhrenmonitoren für den Overscan nötig war. Brauchst du mehr Platz, kannst du das auch weglassen... einfach mal damit experimentieren. Danach kommt der Befehl $40 (64). Dieser Befehl (echt verwirrend am Anfang) sagt dem Antic, wo der eigentliche Bildschirm im Coputerspeicher startet. Hinter dem $40 kommt also zunächst der Low-/ dann der Highbyte - Wert des Startbildschirmes im Speicher - oft an $9c40 (40000). Danach kommen x-Werte - nämlich die Anzahl der Zeilen je nach Grafikmodus, die Zahlen selber entscheiden über den jeweilige Grafikmodus. Will ich z.B. Graphics 0 haben (Antic 2 - die Nomenklatur weicht zu Basic ab), dann nehem ich also 23x 2 für 24 Zeilen. Dabei kommt jetzt ein echt unnötiger Zusatz: die erste Zeile wird direkt noch dem Befehl $40 mitgegeben - also $40+2 = $42 !! Man kann so übrigens auch fast beliebig die entsprechenden Grafikstufen Zeile für Zeile anders gestalten. Das macht das System so schön flexibel. Ganz am Ende kommt dann mit $41 (65) ein letzter Befehl - der Sprungbefehl mit enstprechender Adresse - nämlich den Anfang dieser kleinen Routine.

Ein sehr großer Vorteil dieses Aufbaus ist, daß man u.a. mit einer einzigen kleinen Speicheränderung den gesamten Bildschirm bewegen kann - im Maximum 8 kB zeitlos...

Wenn du Fragen hast, dann frag!

LG Peter

Hallo Peter,

Dr. Irata schrieb: Danach kommt der Befehl $40 (64).

soweit ich weiß steht die $40 nicht alleine. Vielmehr handelt es sich um das gesetzte Bit 6 in der ANTIC-Zeile.

Bei Grafik 0 mit LMS also $42 gefolgt von der Speicheradresse. Oder irre ich mich?

CU, Erhard

... ja klar ... habe ich etwas weiter unten erklärt!

Thema Hintergrundfarbe:

Du hast colbk nicht definiert. endless jmp endless geht einfacher: jmp * alles andere kann man so machen!

Wieso auslachen? Wir haben alle so angefangen und es ist echt komplex am Anfang... weiter so!!

yup - hast du 😉

ich nutze als include immer icl 'hardware.txt'

die hat alles drin!

Noch ein kleiner Hinweis...

Wenn man Hex-Werte eingeben möchte, geht das auch mit der Direktive:

   .he 70 42

Hier hätten wir dann einmal 8 Leerzeilen und dann ein LMS+Gfx 0. Nach dem LMS dann noch:

   .wo screen

und es wird noch leserlicher. .wo und .by kann man in MADS (meist) statt .word und .byte nutzen.

Edit: Noch eine Sache für die Lesbarkeit... die :Anzahl Direktive für die Wiederholungen kann man auch ganz am Anfang der Zeile schreiben, dann sieht man einfacher, was im Rest so gem8 wird...

DL
:3    .he 70
      .he 42
      .wo screen
:23   .he 02
      .he 41
      .wo DL

Mein Start war so ähnlich wie bei dir - allerdings hatte ich gleich nach kurzer Einarbeitung ein klares Ziel: ich wollte den Vertikalshooter Phobos nachprogrammieren, was ich letztlich auch tat: Battle of Eris - das Jahr danach war dann Teil 2 dran, Caverns of Eris (kannst du dir mal bei youtube anschauen)... alles ist möglich und es macht riesig Spass... wirklich toll und aufregend für dich!!

Du kannst natürlich kleinere Bereiche des Bildschirmes einfach umkopieren... bei richtiger Wahl der Auflösung und des Bildschirmes geht das auch recht flüssig. Bei Caverns of Eris arbeite ich zB komplett ohne Atari-Scrolling, da nutze ich Softwaresprites...

yMoreT8 schrieb: Muss ich immer den gesamten Bildschirm scrollen, oder geht das auch Zeilenweise? Ich hab so viele Fragen... aber fangen wir mal klein an

Du kannst jede Zeile unabhängig scrollen ohne die Bildschirmdaten tatsächlich zu bewegen ; ANTIC und der Display List sei Dank.

Ein super Tutorial in Englisch findest du hier : https://playermissile.com/scrolling_tutorial/index.html

Rob hat auch eines zu DLIs verfasst, die dir noch mehr Möglichkeiten zum Zaubern auf dem Bildschirm geben.

yMoreT8 schrieb: Makro einen Speicherbereich initialisieren, sowas wie $00 * 24 * 40 ?

Das liest sich zwar sehr kurz, würde aber in einer Porgrammdatei 960 Bytes belegen. Und nicht nur das. Der Speicher würde nur einmalig beim Laden der Datei initialisiert.

Wenn er im Verlauf des Programms erneut auf einen bestimmten Wert gesetzt werden muß geht das nicht, wenn kein Programmcode da ist, der das macht.

LDX #0
TXA
LOOP STA MEMORY,X
STA MEMORY+$100,X
STA MEMORY+$200,X
STA MEMORY+$300,X
DEX
BNE LOOP
RTS

Keine Ahnung ob der Code optimal ist.

Man könnte auch gleich eine Routine schreiben, die einen beliebigen Speicherbereich (von-bis oder von+länge) mit einem beliebigen Wert füllt und diese Route dann mit Parametern aufrufen.

CU, Erhard

cool !